Student System – CRUD · API · S3 Lifecycle · VPC/ALB · Simulation Exam

End-to-end Student System

This page bundles all design views used in class:

• UI – CRUD tab – Student list, add/update/delete, upload picture.
• API Design tab – REST endpoints, request/response JSON, picture upload flow using S3.
• RDS Schema tab – students table with picture_key stored in the database.
• S3 & Lifecycle tab – How pictures are stored, Standard → IA → Glacier, and restore flow.
• VPC / ALB 3-Tier tab – Network & compute architecture for the API and database.
• Simulation Game (Exam) – Incident scenarios for CloudWatch, CloudTrail, S3 lifecycle & security.

Student Management UI (Wireframe)

A simple UI that sits on top of the API and RDS database.

• Top bar: module name, class, and environment (Dev / Test / Prod).
• Table of students: id, name, email, course, picture, actions.
• Buttons: Add Student, Refresh.

UI → API calls

• GET /students – Load all students.
• POST /students – Create student (JSON body, no picture yet or with picture key).
• PUT /students/<id> – Update student details.
• DELETE /students/<id> – Delete student (and optionally picture in S3).
• POST /students/<id>/picture – Upload picture:
  • Front-end calls POST /students/<id>/picture/presign.
  • API returns presigned URL for S3.
  • Browser uploads file directly to S3.
  • API stores picture_key in RDS.

Core REST Endpoints

1. List & detail

GET /students
200 OK
[
  {
    "id": 1,
    "name": "Alice",
    "email": "alice@example.com",
    "course": "DIT",
    "picture_key": "students/1/profile.jpg",
    "picture_url": "https://.../students/1/profile.jpg"  // presigned or CloudFront URL
  },
  ...
]

GET /students/<id>
200 OK
{
  "id": 1,
  "name": "Alice",
  "email": "alice@example.com",
  "course": "DIT",
  "picture_key": "students/1/profile.jpg"
}

2. Create / Update / Delete

POST /students
Request:
{
  "name": "Alice",
  "email": "alice@example.com",
  "course": "DIT"
}

Response 201:
{
  "id": 1,
  "name": "Alice",
  "email": "alice@example.com",
  "course": "DIT",
  "picture_key": null
}

PUT /students/<id>
Request:
{
  "name": "Alice Tan",
  "course": "DIT-SC"
}

DELETE /students/<id>
- Marks student as deleted
- Optionally queues a task to delete picture from S3

3. Picture Upload – using S3 + picture_key in DB

Step 1 – Get presigned URL

POST /students/<id>/picture/presign
Request:
{
  "contentType": "image/jpeg"
}

Server:
- Builds key: "students/<id>/profile.jpg"
- Stores/updates picture_key in DB
- Calls AWS SDK S3: getSignedUrl("putObject", ...)

Response:
{
  "uploadUrl": "https://s3....",
  "pictureKey": "students/<id>/profile.jpg"
}

Step 2 – Front-end uploads directly to S3

PUT uploadUrl
Headers: Content-Type: image/jpeg
Body:   binary image data

Step 3 – Get picture for UI

When UI calls GET /students, backend can:

• Return the raw picture_key only, and front-end calls another API to get a presigned GET URL.
• Or generate a short-lived picture_url in the list response.

MySQL / MariaDB – students table

CREATE TABLE students (
  id           INT AUTO_INCREMENT PRIMARY KEY,
  name         VARCHAR(100) NOT NULL,
  email        VARCHAR(150) NOT NULL UNIQUE,
  course       VARCHAR(50)  NOT NULL,
  picture_key  VARCHAR(255) NULL,
  created_at   TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  updated_at   TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

• picture_key stores the S3 object key (e.g. students/1/profile.jpg).
• The actual picture file is stored in S3, not in the database.
• If lifecycle moves object to Glacier, picture_key still remains the same.

Sample data

INSERT INTO students (name, email, course, picture_key) VALUES
('Alice', 'alice@example.com', 'DIT', 'students/1/profile.jpg'),
('Ben',   'ben@example.com',   'DIT-SC', 'students/2/profile.png'),
('Cara',  'cara@example.com',  'DFI', NULL);

S3 Bucket for Student Pictures

• Bucket: sp-students-pictures-<env>
• Folder structure:
  • students/<id>/profile.jpg
  • students/<id>/history/...
• Access via:
  • Presigned URLs (GET & PUT) from the API.
  • CloudFront distribution (optional) for faster delivery.

Lifecycle Policy

• After 30 days – move from Standard to Standard-IA.
• After 365 days – transition to Glacier Instant Retrieval or Glacier Deep Archive.
• Optional: expire objects after X years for alumni.

Rule: "student-pictures-lifecycle"
Filter: prefix = "students/"
Transitions:
  - Days: 30, StorageClass: STANDARD_IA
  - Days: 365, StorageClass: GLACIER_IR

Important: When object is in Glacier, direct GET may return InvalidObjectState. Application must:

• Call restoreObject first (or handle restore via EventBridge + Lambda).
• Show "restoring picture..." in UI.

3-Tier Network Architecture

• VPC with public and private subnets across 2 AZs.
• Public subnets: ALB.
• Private subnets: EC2 app instances + RDS.
• S3 accessed over public endpoint or VPC endpoint.

High-level flow

• Student → Internet → ALB (HTTPS).
• ALB → App EC2 → RDS (for metadata & picture_key).
• App EC2 → S3 (Get/Put object) using IAM role.
• CloudWatch + CloudTrail log metrics and API calls.
• EventBridge reacts to lifecycle or security events.